vlwkaos' digital garden

웹 텍스트 에디터 개발, 어떤 형태가 좋을지에 대한 답변

어제 테크밋 발표 이후 올라온 질문 중, 여러 웹 텍스트 에디터 개발 방법 중 어떤 걸 선호하는지, 어떤 방식이 유지보수에 용이할지에 대한 질문이 올라왔다. 정말 오랜만에 여러 사람 앞에 있다보니 긴장을 많이 한 것 같다. 내 생각을 온전히 전달하지 못하기도 했고, 듣는 사람에게도 시원찮은 답변이었을 것이라 생각하여 한번 정리하고 가기 위해 글로 작성한다.


Q. 다음 3가지 중 개인적으로 선호하는 에디터 개발 방향이 있을까요?

  1. contenteditable 사용하기
  2. 입력만 textarea나 input으로 받고 커서 직접 구현하기
  3. canvas 활용하기

A. 이 질문은 문서 제어권을 가져오기 위해 어느 레벨까지 추상화를 할 것인가라는 질문으로 받아들여진다. 3번으로 갈수록 브라우저와 멀어지는데, 멀어지면 멀어질수록 사실상 웹상에서 개발하는 것이 아닌 온전히 응용프로그램 설계의 영역으로 넘어간다. 완벽한 제어가 가능한 만큼, 입력 시스템 그 자체를 개발하는 수준으로 모든 것을 직접 구현해야한다. (브라우저 위에 브라우저를 만드는 느낌이다.)

그러니 결국 내가 가진 자원이 얼마나 되는가를 고려하지 않을 수 밖에 없다. 발표에서도 얘기했지만, 텍스트 에디터 개발에는 당연시 여겨지는 것에 비해 정말 고려해야할 것들이 많다. 반면 많은 회사는 개발자를 기다려주지 않을 것이다 (이 당연한게 왜이렇게 오래걸려?). 자원이 적을수록 브라우저에게 위임할 부분은 위임할 수밖에 없다. 그렇기 때문에 선호하는 개발 방식은 1번이다. 이것은 contenteditable을 주어진대로 사용하는 것을 의미하는 것은 아니다. 그럼에도 제어권을 가져올 수 있는 영역은 추상화를 해야한다. 추가로 발표 마지막에 얘기 했던 미래의 텍스트 에디터 개발은 결국 contenteditable 기반에 EditContext 같은 web API를 활용하는 형태일 것이라 생각하면 이 방식에 익숙해지면 좋지 않을까 생각한다.


Q. monaco editor, Prosemirror 는 직접 커서를 구현하고, 페이스북의 Lexical 에디터의 경우 contentEditable의 각각의 브라우저 마다, 기기마다 상이한 에디터에 대한 호환 코드로 대응하는 데, 좀 더 유지보수에 유리한 형태는 어느 것이라고 생각하시나요?

A. 아마 당시에는 뭉뚱그려서 "결국 추상화를 어떻게 하냐에 달려있는 것같다" 라고 얘기를 했다. 그 이유는, 어떤 방법을 사용하든 틀린건 아니기 때문이다. 유지보수가 유리하게 하는 것은 어떤 방법을 사용했느냐보다 코드 레벨에서 레이어를 잘 나누고 설계를 잘 하는 것과 팀 차원에서 히스토리 파악을 용이하게 하는등 비기술적 장치를 마련해 두는 것에 달려있다고 생각한다. 예를 들어 lexical의 코드를 보면 브라우저마다 호환코드로 대응하는 것에는 문제가 없지만, 코드베이스가 함수 기반으로 구성이 되어있어 코드의 전체적인 설계를 파악하기 어렵다는 점, 모듈 간 바운더리도 존재하지 않아 간섭이 심한 부분등 여러 '빨간불' 이 많이 보였고 지속이 불가능한 프로젝트 아닌가? 라는 생각이 들었다 (어쩌면 그래서 오픈소스로 미완성 공개가 되지 않았나 싶다). 응용 프로그램은 명확하게 설계가 되어야하고, 누구나 파악할 수 있도록 도식화할 수 있어야 지속이 가능하다.

Referred in

웹 텍스트 에디터 개발, 어떤 형태가 좋을지에 대한 답변